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Abstract 


RFC 3777 defines the Nominations and Recall Committee’s (NomCom’s) 
operation, and includes a sample timeline for major steps in the 


NomCom process that meets the minimum normative requirements for the 


process. Recent NomComs have been scheduling based on the sample 


timeline, and the chairs of the last three NomComs -- Danny McPherson 


(2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) 


have all reported that this timeline is very aggressive and suggested 


starting earlier. This document restructures the sample timeline, 
but makes no normative process changes. 
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1. Introduction 


RFC 3777 ([RFC3777]) is a complete specification of the process by 
which members of the IAB and IESG are selected, confirmed, and 
recalled as of the date of its approval. [RFC3777] includes 
normative requirements for timing allowed for the various steps, and 
also includes an informative appendix, Appendix B, that contains a 
timeline based on the normative text. 


The normative time requirements in [RFC3777] are end-of-task, so 
adjusting the informative timeline to get an earlier start does not 
require changes to the normative text in [RFC3777]. 


In IETF 68, IETF 65, and IETF 62 plenary reports, NomCom chairs 
suggested starting the NomCom cycle earlier. This document describes 
a timeline that meets this need, replacing RFC 3777, Appendix B, and 
makes no other changes to [RFC3777]. 


2. The Problem 


There are several reasons that have been cited for the schedule 
pressures reported by recent NomComs. 


o A few common practices are not accounted for in the Appendix B 
timeline [RFC3777]. For example, it is common to allow a week for 
notifying unsuccessful nominees before the formal announcement is 
made. This is not included in the timeline. 


o Some tasks just seem to take longer than the minimum interval. 
For example, a public "call for volunteers" must be open for 30 
days, but the list of voting NomCom participants probably isn’t 
announced at midnight on the 30th day. Anecdotal evidence is that 
allowing about 6 weeks is more consistent with recent experience. 


o The NomCom, and the community it serves, tends to celebrate a 
variety of holidays between the third IETF and the first IETF of 
the next year, so people may be out of the office, may wait to 
respond, etc. 


o The Appendix B timeline does not provide flexibility in case of 
problems. For example, the NomCom chair "reset" the random 
selection of volunteers for the 2006-2007 NomCom, requiring 
another seven-day delay for the announcement of the date of random 
selection. 


All of these reasons can be accommodated by simply starting earlier 
than is absolutely required. 
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Interaction with IETF Face-to-Face Meeting Schedule 


In addition to these reasons for schedule pressure, it’s worth noting 
that the NomCom schedule and the IETF face-to-face meeting cycle 
don’t complement each other. 


o When the NomCom volunteers are selected after the second IETF, 
they don’t have an opportunity to meet face-to-face and "get 
organized" until the third IETF, when they should be winding up 
their deliberations. This missed opportunity forces them to use 
teleconferences and other less efficient means of communications 
to get organized. 


o The NomCom volunteers don’t have a chance to conduct interviews 
with the community, or with nominees, until the third IETF, during 
the height of the NomCom effort. If the NomCom effort took place 
before the third IETF, the NomCom could work on difficult 
nominations, and meet face-to-face with nominees under 
consideration. 


o If the NomCom is able to start interviews during the second IETF 
meeting, starting earlier than is absolutely required may also 
help NomCom be more effective. 


Proposed Solution 


The high-level description of the proposal is, of course, "start 
earlier", but more precision would be helpful. 


A sample, hypothetical timeline that meets these guidelines is shown 
in Section 5. Please note that, like Appendix B in [RFC3777], this 
timeline is not normative, but it meets the normative requirements 
stated in [RFC3777]. 


Other timelines are certainly possible, including timelines that 
allow the NomCom to report its results more than one month before the 
first IETF, where the slate of nominees is announced. Finishing 
early may be a good thing. 


It’s worth noting that the first step in the timeline is "ISOC 
president appoints NomCom chair". This doesn’t happen as an IETF 
responsibility, but the reality is that the ISOC president needs to 
identify NomCom chair candidates around the time of the first IETF; 
she needs to have a shortlist 3 or 4 weeks after the first IETF. 
This document suggests (but does not add a normative requirement to 
[RFC3777]) that the outgoing NomCom Chair should verify that this 
process is triggered during the first IETF. 
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1. One week is allowed for the NomCom chair to publish milestones. 

2. Six weeks are allowed for solicitation of NomCom participants. 

3. One week is allowed for confirmation of the selection of voting 
members -- to allow at least some time for resolution if there is 


a problem. 


4. The recommended time for NomCom self-organization is increased to 
six weeks. 


5. One week is allowed for NomCom establishing milestones. 


6. In the sample timeline (Table 1), an additional five weeks is 
allowed for the nominating bodies to select candidates. 


7. The timeline is adjusted to allow one week at the end of the 
process for notification of unsuccessful candidates. 


This significantly increases the amount of time available for NomCom 
to select candidates while still meeting the normative requirements 
of [RFC3777]. 


5. Sample Timeline for 2008-2009 NomCom Schedule 


The following table shows a sample timeline for the 2008-2009 NomCom 
schedule, based on the IETF dates for the second IETF (72nd IETF, 
held July 27 - August 1, 2008), third IETF (73rd IETF, held November 
16-21, 2008), and first IETF (74 IETF, held March 22-27, 2009). 


Note that the duration of each milestone step is adjusted as 
necessary for each NomCom, since the scheduled dates for IETF 
meetings vary from year to year. This timeline allows the NomCom to 
begin self organizing at the Second IETF (this is what "on time") 
means in the table). 
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4+------------ 4+----------------- 4+---------- 4-------------- 4+---------- + 
| RFC 3777 | What happens | new | start date | old | 
Appendix B duration (YYYY/MM/DD) duration 
reference (weeks) (weeks) 


ISOC president 
appoints NomCom 
chair 
NomCom chair 
publishes 
milestones 
Solicitation of 
NomCom 
participants 
Announce date 
of random 
selection 
Announce NomCom 
membership, 
challenge 
period 
Verify NomCom 
membership 
during 
challenge 
period 
Confirm NomCom 
membership 
NomCom self 
organizes (on 
time) 

END 
organization, 
BEGIN selection 
NomCom 
establishes 
milestones 
Nominating 
bodies select 
candidates 
END selection, 
BEGIN 
confirmation of 
candidates 
Present slate 
of candidates 
to confirming 
bodies 


2008/05/25 


2008/05/25 


2008/06/01 


30 days 


2008/07/13 


2008/07/20 


2008/07/27 


2008/07/27 


2008/08/03 


2008/09/14 


10 2008/09/14 


11 17 2008/09/21 12 


12 2009/01/18 


13 2009/01/18 


i tt 
LH 
a E 
a 
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| 14 Confirming | 2009/01/18 
| bodies accept | 
| or reject | 
(added Notify 
| step) unsuccessful | 
| nominees | 
| Slate announced | 
| 1 month before | 
lst IETF 
lst IETF 2009/03/22 


4+------------ 4+----------------- 4+---------- 4+-------------- 4+---------- + 


2009/02/22 


| 
| 
1 | 2009/02/15 
| 
| 
| 
| 


New Step 1 Date: 2008/05/25, Old Step 1 Date: 2008/08/29 
Table 1 
6. Some Observations from the 2007-2008 NomCom Experience 


Since the timeline described in this specification makes no normative 
changes to [RFC3777], the 2007-2008 NomCom process started using the 
new timeline to gain experience and shake out unexpected 
consequences. We discovered the following things: 


1. It is worth pointing out that the [RFC3777] requirement for 
eligibility, "Members of the IETF community must have attended at 
least 3 of the last 5 IETF meetings in order to volunteer.", is 
affected when the NomCom chair issues an earlier call for 
volunteers. For example, using the 2008-2009 NomCom example in 
the doc: under the old schedule, a prospective member would need 
to have attended three of IETF meetings 68-72. Under the new 
schedule, that becomes three of IETF meetings 67-71. 


2. It’s worth noting that when NomCom uses the earlier timeline, 
incumbents under review who were appointed to one-year terms have 
only one IETF meeting cycle to establish a track record before 
NomCom begins considering whether they should be retained. This 
Situation is rare but not unknown. The recent split of the RAI 
area out of TSV created two one-year terms (one in RAI, and one 
in TSV), and this can also happens if an IESG or IAB member 
resigns with more than one year remaining in the member’s term. 


7. Out-of-Scope Suggestions Requiring Normative Text Changes 


While there are very few avoidable serialized delays in [RFC3777], we 
note that the minimum 30-day delay for volunteers is serialized after 
the NomCom chair is named. This delay accounts for more than half 

the elapsed time between the NomCom chair being named and the NomCom 
itself forming. If a future normative revision to [RFC3777] changed 
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the mechanics for this call for volunteers, this call could be issued 
while the NomCom chair is still being selected. This would allow the 
new NomCom chair to begin work by announcing the date of random 
selection, instead of just waiting for the volunteers to volunteer. 


One possible trigger would be to have the outgoing NomCom chair issue 
the call for volunteers on behalf of the successor NomCom chair, who 
may not yet be identified, at the first IETF meeting each year. 


Security Considerations 


The NomCom timeline changes suggested in this document do not 
directly affect the security of the Internet. 


Acknowledgements 


This draft is based on conversations with the chairs of the last 
three NomComs: Danny McPherson (2004-2005), Ralph Droms (2005-2006), 
and Andrew Lange (2006-2007), and on their corresponding plenary 
NomCom Report presentations at IETF 62, IETF 65, and IETF 68, 
respectively. 


The 2007 IESG discussed Andrew Lange’s report at their face-to-face 
retreat and requested a proposal that adjusted the informative 
timeline with no normative changes. 


Thanks to Russ Housley, current General Area director, for reviewing 
an early version of this draft. 


Thanks to Brian Carpenter, who pointed out that the IETF NomCom 
portion of the timeline depends on the ISOC president appointing the 
NomCom chair soon after the first IETF ("NomCom chairs don’t appear 
magically"), and provided a suggestion for ensuring that this happens 
in a timeframe that allows NomCom to begin self organizing at the 
Second IETF meeting each year. 


Thanks to Sam Weiler, who pointed out the shift in meeting attendance 
requirements described in Section 6. 


We should also thank the editors of previous NomCom procedures for 
developing a specification that we could "speed up" without changing 
normative text. 


Normative References 
[RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 


Recall Process: Operation of the Nominating and Recall 
Committees", BCP 10, RFC 3777, June 2004. 


Dawkins Informational [Page 7] 


RFC 5078 NomCom Starting Earlier October 2007 


Author’s Address 


Spencer Dawkins 

Huawei Technologies (USA) 
1547 Rivercrest Blvd. 
Allen, TX 75002 

USA 


Phone: +1 469 229 5397 
EMail: spencer@mcsr-labs.org 


Dawkins Informational [Page 8] 


RFC 5078 NomCom Starting Earlier October 2007 


Full Copyright Statement 
Copyright (C) The IETF Trust (2007). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 


Dawkins Informational [Page 9] 


